Slightly related, as it eases finding such issues: #3441

This issue just popped up in slack when there is an error like OPcache already loaded

I think we should reconsider if the check really has to be done at (production) runtime or if this should be part of the (one time) neos setup (./flow setup and /setup endpoint). Adding this validation to the setup would allow us to give more verbose output to the user. Like if the php binary emits odd stuff i want to know about it ^^. But if this all has to be be encapsulated when the actual runtime code already attempts to start a php subprocess its a little late for this guidance. (Especially if this is deployed already wrongly)

So i think we should try to remove the (expensive) php validation here from the Scripts and instead fully put the load to the setup with more verbose information. The only problem is that we need to see if we want people to have the neos setup package installed on the production server to see possible problems ... maybe hidden by login after all...

But in the setup this doesn't help at all. Mostly I run into this during changing the PHP versions in already productive running systems and you forgot to change the binary path in the config.

Hmmm, I think it is problematic to remove this check if we cannot hint to the user that something is wrong. In fact we would need to point the user to the setup in error cases; otherwise they will not find it... I need to think it through more carefully though.

when there is an error like OPcache already loaded

With #3441 the cause should be clearly visible. And then you can just fix it, no?